制約を読まないエンジニアへ - 弁護士ドットコム株式会社 Creators’ blog
https://gyazo.com/e9fba26003494e2839720a66b92e012b
モジュラーモノリスという選択肢はなかったのか。ビルドやテストの仕組みを改善する余地はなかったのか。モノレポのままでも、モジュール境界を厳格にする道は検討されたのか。あるいは、分割するにしても、それは本当にドメインの理解に基づいたものだったのか。 An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
（アーキテクチャスタイルとは、アーキテクチャ上の制約を協調的にまとめたものであり、そのスタイルに準拠するあらゆるアーキテクチャにおいて、構成要素の役割や機能、および要素間の許容される関係を制限するものである。） 先人たちは、自由度を増やすことが常に良いわけではないことを知っていました。だからこそ、あえて制約を置いたのだと思います。
道具の使い方は知っている。しかし、なぜその道具がその形をしているのかには関心が向かない。 リニューアルの前半は楽しい。構想があり、図が描ける。しかし後半には、移行、互換性、運用、データ整合性、既存資産との接続、負債の返済が待っています。システム開発の難所は、たいていそこにあります。 そして組織はしばしば、この後半をうまく報いません。新しいものを始める人は評価されやすいのに、それを事業の現実に接続し、泥を被りながら完遂する人は可視化されにくい。結果として、大きな刷新は「始める人」と「最後まで背負う人」が分離しやすい。
現実には、壮大な刷新ほど前半の意思決定が称賛され、後半のしんどさは組織に残る。この現象を、わたしは「責任の蒸発」と呼びたくなります。 ここでいう責任とは、個人の矜持の問題ではありません。むしろ、組織が大規模刷新をどう評価し、どう引き継ぎ、どう完遂責任を持たせるかという設計の問題です。矜持の不足というより、矜持に依存しなければ回らない仕組みのほうに、より大きな問題があるのだと思います。